Does Port Explorer inject
any code into other processes?
No, absolutely not. Some other port-to-process mappers do this as it is
sometimes possible under the right circumstances for a program to inject code
into the memory space of other processes and execute that code, effectively
having their own code running as the other process, but Port Explorer does not
and will never do this. Code injection is not only an unreliable method
(incorrect and missing results can often occur, and many processes can't have
code injected into their memory area anyway) but it is also a very dangerous
practice (trojans even use it to bypass some personal firewalls) and can have
adverse effects on the processes that have been injected, sometimes causing
processes to malfunction or crash. In some cases, system instability and even
blue-screens-of-death (BSOD) can result. Code injection usually fails on
protected system services, and in many cases the code being injected is
overwriting existing code. We advise against using such programs on your
system for these reasons, or if you do use them then reboot your computer
afterwards.
Does Port Explorer patch or
modify any files on my computer?
No. For a full listing of all files that are installed/created by Port
Explorer, see this page.
Port Explorer takes a few seconds to load before I see anything, is this normal?
Yes, this is normal. Port Explorer has a complex but important
initialisation sequence that will take approximately one second on fast
computers, and several seconds on slower computers. Actual performance
with Port Explorer running is very fast.
Does Port Explorer suffer
from any of the problems that plague most port-to-process mappers?
No. For a full listing of all problems commonly associated with other
port-to-process mappers (and how Port Explorer solves these problems), see this page.
Why does Task Manager show PortExplorer.exe as having lots of page faults?
A page fault is basically a hardware event that occurs when a process tries to access an address in virtual memory that does not have a location in physical memory associated with it. In response, the system tries to load the appropriate data into a newly assigned physical
page. Page faults are completely harmless and virtually all processes on your
system will generate page faults at some stage. Port Explorer generates some
page faults with every display refresh it invokes (usually every 3 seconds),
which is why it will usually have more page faults than 'static'
processes.
Please note that page faults are not
exclusive to Port Explorer - all programs generate page faults at some stage (as
any process viewer such as Windows Task Manager will reveal). Other
port-to-process mapping utilities generate page faults at a rate comparable to
Port Explorer, and you should find that the rate of page faults generated is
directly affected by the refresh rate of the program -- the more refreshes, the
more page faults.
What settings can be adjusted to make Port Explorer run more smoothly on slower computers?
Hide Netstat Sockets - If there are less sockets to display, Port
Explorer can update the list more quickly.
Disable Sorting - Sorting requires a lot of calculations. Having it
disabled can improve the list display speed.
Refresh Interval - By setting this to a slower value (such as 5 seconds
or more) you can improve the performance of Port Explorer.
Show Resolved Addresses - By turning this option off, Port Explorer
performance can be improved as it won't try to resolve any addresses.
Pause Display - By pausing the display (F2 keyboard shortcut) you can
prevent Port Explorer from updating the list. The list can be manually updated
by pressing F5.
What does the TIME_WAIT
state mean?
When a socket is closed it goes into a TIME_WAIT state for a certain period
(usually 240 seconds). This is to ensure that all the data it has sent has gone
through (including the 'FIN' packet to finish the connection), and also to
prevent the connection from being re-used and accidentally receiving data meant
for the old connection. TIME_WAIT sockets can essentially be ignored by most
users.
Why is Port Explorer
listening on a port?
This generally only applies to systems using a proxy service (such as
Winsock proxy), such as workstations in a local area network.
Port Explorer doesn't use any socket-opening/listening commands so it is not
possible for Port Explorer itself to listen on a socket. However, Port Explorer
uses several DNS-related functions (such as gethostbyname()
and gethostbyaddr()),
that, depending on your system configuration and whether or not you're using a
proxy service, may cause a socket or possibly multiple sockets (UDP and/or TCP)
to listen for returned DNS responses. If you see Port Explorer listening on any
sockets, it is safe to assume they're just open for DNS address resolving.
Why do some processes show as --NETSTAT-- when others display the actual process?
Under Windows 95/98/ME, Port Explorer isn't always able to map all ports back to their parent processes.
This is because some of these processes (system services) start before Port Explorer is
initialised by the operating system. However, the common "netstat"
program can see them, so Port Explorer combines both results into one table,
showing the netstat sockets as '--NETSTAT--'.
TIME_WAIT sockets will also often
display as --NETSTAT--, as the system has taken ownership of these sockets.
What do the colors of the sockets (red, black,
blue) indicate?
Each color indicates the type of parent process that the socket belongs to.
The colors can be altered to your personal preferences, but the default
colors are:
Blue - system process. These are processes
that normally start as services.
Black - normal process. Most applications will display in this
color. Black indicates that the program has at least one visual property,
such as a window, that is on-screen.
Red - hidden process. Rare, as this only
applies to hidden servers - processes that run invisibly but use sockets (as
nearly all remote access trojans do). This
is extremely efficient at detecting trojans, but red doesn't necessarily confirm
that a process is a trojan. Sockets can also display as red if their parent
process has hung or crashed but not yet terminated.
For a further detailed explanation, please see Socket
Colors.
What attributes causes a program to
display as a red socket?
Put simply, if Port Explorer determines that the process has no visual
properties (eg. no on-screen windows), it will highlight the socket with red
text. This is extremely effective in detecting remote access trojans. However,
there are a couple of exceptions to the rule:
- System services will display as blue, even if they are invisible (most
are). It is possible for a trojan to run as a system service, but this is very
rare and not a common trojan practice.
- Programs that have crashed but hanged before completely terminating may
have their sockets appear as red, because although the process may still have
visual properties on screen such as a dialog window that refuses to close, the
process itself has crashed and Port Explorer (or any other program for that
matter) will not be able to detect the crashed/hung window.
- System-tray icons do not currently count as a visual property as there
is currently no known way to 'map' a system tray icon back to its parent
process, as the system tray is handled by explorer.exe. Therefore, programs will
show as red if they have a system tray icon but no other visual property.
- Port Explorer uses intelligent algorithms to check the position and size
of windows, so windows that are visible but are off-screen will not be counted
as a 'visual property.
I close a socket but it keeps
re-opening, why?
Although Port Explorer is successfully able to close most active sockets, it
is not possible to prevent the host program from detecting the closure and
immediately re-opening the port. If Port Explorer did automatically do this, the
host program would go into a never-ending loop where Port Explorer would attempt
to terminate the socket, the host program would detect the closure and re-open
the socket, and then the loop would start again. Please note that this only
works on sockets that are in an ESTABLISHED state.
Can Port Explorer be used as a
firewall?
No, Port Explorer is not and can not be used as a firewall. However, Port
Explorer does give you control over sockets ability to send and/or receive data,
and also lets you close individual sockets.
Is Port Explorer a packet sniffer?
Port Explorer is not a dedicated packet sniffer, but the advanced Socket Spy
utility does give you the
unique and powerful capability to packet-capture/spy on individual sockets and processes, allowing you to see data
that dedicated packet-sniffers can see but without having to filter through
unwanted data. The ability to spy on specific sockets and/or processes is a
capability unique to Port Explorer and is explained in detail in the Advanced
section of this help manual.
Do I need to allow Port Explorer access through my
personal firewall?
You don't have to, but it is recommended. If you block
Port Explorer with your firewall you won't be able to do such things as
resolve/traceroute/ping addresses, or use utilities such as the Whois client,
but these would be the only restrictions.
If I close the portexplorer.exe program down, is Port
Explorer still running?
Yes and no - portexplorer.exe will no longer be running, but dcsws2.dll (the
DiamondCS TCP/IP layer) will still be active in a similar way that Winsock and
other system services always remains 'active'. However, dcsws2.dll will only be active if
at least one process on your system is using TCP/IP.
Are there any known issues with running Port Explorer alongside
firewalls, anti-virus or other low-level software?
We aren't aware of any such issues and we don't anticipate any as Port
Explorer is very much a standalone program that doesn't interfere with any other
programs. If you do suspect a problem, it is highly unlikely that Port Explorer
is the cause, but please see the Troubleshooting
page for this question:
I think Port Explorer may be causing
errors/problems on my system, how can I verify the source of the problem?
The instructions listed will guide you through a
simple process that will allow you to pinpoint the cause of the problem. The
technique is very useful and can be used to pinpoint the cause of most software
problems.